1. There is a metadata file called “ocpn-plugins.xml” which contains a description, tarball URLs, and potentially other stuff for a set of plugins.
2. The ocpn-plugins.xml file is created by merging the files in plugins/metadata. Each of these files represents a plugin build for a given platform.
3. When placed in the OCPN private data directory, OCPN will (at startup) notice the metadata, and offer a GUI interface to “manage” the so-described plugins.
4. Each plugin metadata section in ocpn-plugins.xml may (will?) be platform specific.
5. Legacy (user-managed) plugin installers (by .exe, .dmg, or PPA) can coexist, but are in no way “managed” by the new GUI.

1. I assume OCPN can download at will a new updated copy of ocpn-plugins.xml, on user request.
2. Today, the act of “publishing” a new approved plugin for OCPN consists of creating an entry on the opencpn.org website describing the plugin, and providing links to (soon to be called) legacy installers for user integration and management.
3. In the new scheme, “publishing” a plugin includes all of (6) above, as well as creating and promulgating a new release of ocpn-plugins.xml, properly versioned in some unclear way.

1. We collectively wonder where to host the ocpn-plugins.xml files, with some kind of version control, access privileges, etc.
2. What are the policies as regards this critical file? Who can update the official copy, etc?
3. We also wonder where, or if, to assertively host the tarballs, and other blobs required for installation, for each plugin.

1. Start a new project on github called OpenCPN/plugins, with the same maintainers as OpenCPN/OpenCPN.
2. Move the parts related to building ocpn-plugins.xml to this new project. This includes plugins/metadata, plugins/icons, parts of tools/and parts of CMakeLists.txt which creates ocpn-plugins.xml
3. The new project basically “exports” ocpn-plugins.xml. It has an independent versioning scheme, perhaps as simple as a single number.
4. Each release of OpenCPN is distributed with a fixed version of ocpn-plugins.xml.
5. The code in OpenCPN PR #1457 is updated so it can update ocpn-plugins.xml by downloading it from from github on user request.

This is about the new Plugin Installer as proposed in [1]

1. For each plugin, the installer needs an XML metadata file and a tarball containing what to install. Together with existing packages (.exe, .img, .deb etc.) this makes three files per plugin.
2. I have forked four example plugins to make them build the necessary stuff for the installer: oesenc [4] , squiddio [3] , radar [2] and bsb4 [5].
3. I have made two pull requests based on my forks: squiddio (merged) and radar_pi [2].
4. The question now discussed is basically how to deploy the stuff built in various ci builders. This is raised as an issue in [3].
5. If this should be handled on a global level (I actually don't see the need at this point) the discussion must IMHO be moved to the overall opencpn project.'

Cheers! Alec

[1] PR #1457 https://github.com/OpenCPN/OpenCPN/pull/1457
[2] Radar_pi https://github.com/opencpn-radar-pi/radar_pi/pull/120
[3] Squiddio_pi https://github.com/mauroc/squiddio_pi/issues/71
[4] Oesenc_pi https://github.com/leamas/oesenc_pi/
[5] Bsb4_pi https://github.com/leamas/bsb4_pi/

The basic counter-question is: compared to bintray, github or what? I can see some general advantages:

1. It actually seems mature.
2. We can create multiple repos for installer stuff (metadata + tarballs), test builds and legacy manual installers. Seems hard on github.
3. With a separate repo for manual packages it becomes more user-friendly (4 files /release instead of 12 for a typical plugin).
4. Cloudsmith has a rich administrative interface.
   1. For example, the retention policy could be set per repo to keep all, keep the latest etc.
   2. This is important to keep the list of test builds manageable.
5. Thanks to a clever scheme there is no need for encrypted deployment keys. Makes life easier for plugin devs.

Still, there is no project decision to use cloudsmith, it's a per-plugin decision to make or not. The only condition is that the plugin artifacts are downloadable from an url, on cloudsmith or elsewehere.

Pros Cloudsmith

1. Mature
2. Free to opensource
3. No need for encrypted deployment keys, which makes life easier for plugin devs.
4. Integrates well with github and circleci.
5. Rich administrative interface.
   1. Retention policy could be set per repo to keep all, keep the latest etc.
   2. Important to keep the list of test builds manageable.
   3. Can make an organization account and can manage & share permissions (and repositories) for that account.
      1. Opencpn organization on github which creates the Cloudsmith Opencpn Organization?
      2. Organization account url https://cloudsmith.io/~opencpn/repos/plugins/packages/
      3. Good for users, easier publishing to Opencpn.org Downloads page links.
      4. Since free/open-source, no billing is required.
      5. Decide who “owns” the opencpn org on Cloudsmith.
      6. Owners can then invite the rest of the plugin developers to the org on Cloudsmith
         1. give them specific read (or write) access to specific repositories.
         2. Maybe each plugin has its own repository, or you create a centralized repository for all of the plugins.
         3. That would be up to the opencpn developers.
      7. Note: Alec's PI Installer does not require centralized repository, flexible source.
6. Allows creation of multiple repositories to host the stable, unstable, manual versions of the binary and xml files.
7. With a separate repo for manual packages it becomes more user-friendly (4 files /release instead of 12 for a typical plugin).
8. Good search features
9. GitHub Actions (new service available to opensource) should be able to export to cloudsmith

Cons Cloudsmith

1. Not a fully integrated github service.
2. Requires another setup and management.

Pros GitHub

1. Integrates fully with GitHub
2. Releases are linked back to Commit Hash
3. Release are serially presented, but searchable

Cons GitHub

1. Release Tab Repository is serially presented.
2. Seems hard to create multiple repros on github.
3. Cannot create multiple repositories in a single account. (stable, unstable, manual)

With some kind of version control, access privileges, etc. What are the policies as regards this critical file? Who can update the official copy, etc? Some ideas:

1. Start a new project on github called OpenCPN/plugins, with the same maintainers as OpenCPN/OpenCPN.
2. Move the parts related to building ocpn-plugins.xml to this new project. This includes
   1. plugins/metadata
   2. plugins/icons
   3. parts of tools
   4. parts of CMakeLists.txt which creates ocpn-plugins.xml
3. The new project basically “exports” ocpn-plugins.xml. It has an independent versioning scheme, perhaps as simple as a single number.
4. Each release of OpenCPN is distributed with a fixed version of ocpn-plugins.xml.
5. The code in #1457 is updated so it can update ocpn-plugins.xml by downloading it from from github on user request.

1. The killer feature is the ability to log in to failed builds when running into trouble. 2. Tokens and encryption is easier, particularly for Win Dev (The simplified token/no encryption is actually cloudsmith). 3. Circleci seems quite fast, although Travis is good too. 4. Circleci information menus are very good, example https://circleci.com/gh/rgleason/squiddio_pi/140